Bandwidth and memory conserving methods for a vehicle navigation system

ABSTRACT

The present invention is directed specifically to methods for reducing the bandwidth requirements for broadcasting traffic information to a vehicle navigation system. The traffic information broadcast to the system using the bandwidth conserving methods of the present invention generally includes traffic flow information and traffic incident information. In one embodiment, the vehicle navigation system filters traffic information to a certain range to expedite traffic calculation, to save on processing hardware, and to reduce bandwidth needs. Alternately, bandwidth conservation may be achieved by providing weight factors and threshold prioritizing when a broadcast limit is close to being reached or exceeded. In another embodiment, bandwidth reduction is achieved by not broadcasting free-flow traffic information and/or displaying only traffic information that indicates a traffic problem. Another method of the present invention to reduce bandwidth needs is directed to reducing broadcast of static traffic information.

RELATED APPLICATION INFORMATION

This application claims priority pursuant to 35 U.S.C. § 119(c) to U.S.Provisional Patent Application Ser. No. 60/560,087, entitled “Method andSystem for Traffic Management Between a Vehicle and Remote Location,”which was filed with the U.S. Patent and Trademark Office on Apr. 6,2004.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and system for providinginformation between vehicles and a remote location and for providingtraffic management and vehicle navigation information between a vehicleand the remote location. More specifically, the present inventionrelates to a traffic management and vehicle navigation system thatexchanges data between vehicles and a remote location while conservingavailable bandwidth and memory resources.

2. Description of Related Art

Navigation systems for determining a route from a start point to adestination point are well known in the art. In addition, navigationsystems having capabilities for determining the geographic position of areference point are also well known in the art (e.g., a GlobalPositioning System (GPS) or a self-contained system having distance andbearing sensors). As an example, a commonly used navigation systemallows a user (or driver) of a vehicle to enter a destination place intothe navigation system. The navigation system then looks up anappropriate route from an original point (using its geographicpositioning capabilities) to the destination point in a road mapdatabase (e.g., the route may be a route having the shortest distancefrom the start point to the destination, one which would take thevehicle the least time, or some other route), and guides the user to thedestination point along the searched route through a visual display orvocal guide.

In searching the appropriate route, some types of mobile navigationsystem use traffic information (e.g., position data on traffic jams;information on roads closed by accidents, construction, or maintenance;lane-regulated locations) delivered from a traffic information supplierin addition to using the road map database. Conventionally, however,known methods for providing and utilizing the above-described trafficinformation for navigation remain very inflexible, cumbersome, andinefficient. For example, one method uses a one-to-one communicationsystem to individually send traffic information streams to a particularvehicle in an attempt to send vehicle specific data to the particularvehicle. A drawback with this method is that many vehicles require thesame information. For example, several vehicles might require the sameregional traffic information. This method, therefore, requires thetransmittal of the same information several times to a plurality ofvehicles, which results in a waste of precious bandwidth. As known inthe art, wireless network bandwidth is extremely sensitive to networkcapacity.

In other methods, the same traffic information is transmitted to allvehicles. The drawback with these methods is that many vehicles areinundated with a large amount of unwanted traffic information. Usersand/or navigation systems are required to sift through the redundant,superfluous, or otherwise unwanted information to pick out pertinenttraffic information.

As a result, there remains a need for systems and methods that allow forthe transmittal of vehicle-related traffic information from a remotelocation to a vehicle and that allow for the selective transmittal ofvehicle related information from a vehicle to a remote location.Moreover, it is desired that the navigation system be provided withenough information to properly determine efficient routes without beinginundated with redundant, useless, and/or superfluous information. Thereis also a need that the information be provided to a user in a useful,efficient, and easily understandable manner.

Accordingly, it would be very desirable to provide a traffic managementarchitecture that overcomes the above-described shortcomings of theprior art while retaining their advantages.

SUMMARY OF THE INVENTION

The present invention addresses the shortcomings of the prior artsystems and methods. In particular, the present invention is directed toa system and method for conserving the bandwidth and hardware resourcesused by a system that transmits vehicle-related traffic information froma remote location to a vehicle and that allows for the selectivetransmittal of vehicle related information from a vehicle to a remotelocation.

Various aspects of the traffic management system are directed to anavigation device, located on a vehicle, that receives broadcastinformation from a one-to-many communication network (e.g., a XMsatellite communication network) and receives/transmits two-waycommunications from/to a back channel network (e.g., a wireless or Wi-Ficommunication network). The present invention is directed specificallyto techniques for reducing the bandwidth requirements for broadcastingtraffic information to the user. The traffic information broadcast tothe user using the bandwidth conserving methods of the present inventiongenerally includes traffic flow information (such as traffic speedinformation for roadways and freeways and other traffic flow orcongestion information), and traffic incident information (such asaccident information, construction information, weather-related eventinformation, and other traffic incident information). Trafficinformation presented to the user of the present invention may alsoinclude information calculated from underlying traffic flow or incidentinformation, e.g., the mileage or estimated travel time on a route thathas higher traffic flow speeds that an originally calculated route.

The present invention encompasses various techniques to overcome thedisadvantageous high bandwidth requirements of the prior art vehiclenavigation systems. Specifically, under an embodiment of the presentinvention, the vehicle navigation system filters traffic information toa certain range (e.g., within a 15 mile radius from the user's location)to expedite traffic calculation, to save on processing hardware, and toreduce bandwidth needs. Alternately, bandwidth conservation may beachieved by the present invention by providing weight factors andthreshold prioritizing when a broadcast limit (e.g., the XM broadcastlimit) is close to being reached or exceeded. The system and method ofthe present invention also can adjust the weight factors as the needarises (e.g., as the broadcast limit is close to being reached). Afurther technique to reduce bandwidth needs in a system of the presentinvention is by not broadcasting free-flow traffic information and/ordisplaying only traffic information that indicates a traffic problem.Another technique employed by the present invention to reduce bandwidthneeds is directed to reducing broadcast of static traffic information.

A more complete understanding of the bandwidth conservation system andmethod will be afforded to those skilled in the art, as well as arealization of additional advantages and objects thereof, by aconsideration of the following detailed description of the preferredembodiment. Reference will be made to the appended sheets of drawingswhich will first be described briefly.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a is a schematic diagram of a first embodiment of a systempursuant to aspects of the invention;

FIG. 1 b is a schematic diagram of a broadcast communication networkpursuant to aspects of the invention;

FIG. 1 c is a schematic diagram of a navigation device in communicationwith a mobile unit pursuant to aspects of the invention;

FIG. 2 is a schematic diagram of an alternate embodiment of a systempursuant to aspects of the invention.

FIG. 3 a is a flow diagram of an embodiment for ensuring quality andreliability of traffic information provided to a vehicle pursuant toaspects of the invention;

FIG. 3 b is a flow diagram of an alternate embodiment for ensuringquality and reliability of traffic information provided to a vehiclepursuant to aspects of the invention;

FIG. 4 is a schematic diagram of an embodiment of a system forcoordinating traffic signals pursuant to aspects of the invention;

FIG. 5 is a flow diagram of an embodiment for coordinating trafficsignals pursuant to aspects of the invention;

FIG. 6 is a schematic diagram of an embodiment of a system for providingautomated and personalized traffic information pursuant to aspects ofthe invention;

FIG. 7 is a schematic diagram of an alternate embodiment of a system forproviding automated and personalized traffic information pursuant toaspects of the invention;

FIG. 8 is a schematic diagram of an embodiment for filtering trafficinformation pursuant to aspects of the invention;

FIG. 9 a is a flow diagram of an embodiment for filtering trafficinformation pursuant to aspects of the invention;

FIG. 9 b is a flow diagram of an alternate embodiment for filteringtraffic information pursuant to aspects of the invention;

FIG. 9 c is a flow diagram of an another embodiment for filteringtraffic information pursuant to aspects of the invention;

FIG. 10 is a flow diagram of an embodiment for providing weight factorsand threshold prioritizing pursuant to aspects of the invention.

FIG. 11 is a schematic diagram of an embodiment of a system thatinitiates a recalculation of a route when there is an upcoming turnpursuant to aspects of the invention;

FIG. 12 is another schematic diagram of an embodiment of a system thatinitiates a recalculation of a route when there is a upcoming turnpursuant to aspects of the invention;

FIG. 13 is a schematic diagram of an embodiment of a system thatperforms a route calculation using traffic information broadcast from aremote location and/or a traffic supplier pursuant to aspects of theinvention;

FIG. 14 is another schematic diagram of an embodiment of a system thatperforms a route calculation using traffic information broadcast from aremote location and/or a traffic supplier pursuant to aspects of theinvention;

FIG. 15 is a flow diagram of an embodiment that uses every trafficinformation update to act as a trigger for route calculation andrecalculation pursuant to aspects of the invention;

FIG. 16 is a flow diagram of an embodiment that uses every trafficinformation update to act as a trigger for route calculation but doesnot recalculate to anticipate user error pursuant to aspects of theinvention;

FIG. 17 is a flow diagram of an embodiment that uses streaming trafficinformation and an internal clock to trigger route calculation and/orrecalculation pursuant to aspects of the invention;

FIG. 18 is a flow diagram of an embodiment that waits for arecalculation to finish and then calculates a new alternate route withtraffic information pursuant to aspects of the invention;

FIG. 19 is a flow diagram of an embodiment that store the trafficinformation when recalculation is taking place pursuant to aspects ofthe invention;

FIGS. 20 and 20 a illustrate an embodiment that stream trafficinformation and varies traffic information update triggers for routecalculation and/or recalculation pursuant to aspects of the invention;

FIG. 21 illustrates an embodiment of a display system pursuant toaspects of the invention;

FIGS. 22 a and 22 b illustrate a case where only traffic incidentinformation is available and addressed by an embodiment of theinvention;

FIG. 23 is a flow diagram of an embodiment for combining actual andhistorical traffic information pursuant to aspects of the invention;

FIG. 24 is a flow diagram of an embodiment for providing a time stamp totraffic incident information and for using the time stamp to determine aroute for calculation pursuant to aspects of the invention;

FIG. 25 is a schematic diagram of an embodiment for filtering trafficinformation without the need of a position determination unit pursuantto aspects of the invention;

FIG. 26 is a flow diagram of an embodiment for filtering trafficinformation without the need of a position determination unit pursuantto aspects of the invention;

FIG. 27 is a schematic diagram of an alternative embodiment forfiltering traffic information without the need of a positiondetermination unit pursuant to aspects of the invention;

FIG. 28 a is a flow diagram of an embodiment for manual filteringtraffic information without the need of a position determination unitpursuant to aspects of the invention;

FIG. 28 b is a flow diagram of an embodiment for automatic filteringtraffic information without the need of a position determination unitpursuant to aspects of the invention;

FIG. 29 is a schematic diagram of an another embodiment for filteringtraffic information without the need of a position determination unitpursuant to aspects of the invention;

FIG. 30 is a flow diagram of an embodiment for filtering trafficinformation using time zones pursuant to aspects of the invention;

FIGS. 31 a and 31 b illustrate an embodiment of a display system havingtraffic flow information and traffic incident information pursuant toaspects of the invention;

FIGS. 32 a and 32 b illustrate an alternative embodiment of a displaysystem having traffic flow information and traffic incident informationpursuant to aspects of the invention;

FIG. 33 illustrates another embodiment of a display system havingtraffic flow information and traffic incident information pursuant toaspects of the invention;

FIG. 34 illustrates yet another embodiment of a display system pursuantto aspects of the invention;

FIG. 35 is a flow diagram of an embodiment for providing a pop-up windowto convey certain traffic information details pursuant to aspects of theinvention;

FIGS. 36 a and 36 b illustrate an embodiment of a display system thatdisplays only traffic information indicating traffic problems pursuantto aspects of the invention;

FIG. 37 is a flow diagram of an embodiment for showing a free-flow iconwhen no data is received on a particular traffic information sensorpursuant to aspects of the invention;

FIG. 38 is a schematic diagram of an embodiment for adding a headerpursuant to aspects of the invention;

FIG. 39 is a flow diagram of an embodiment for adding a header andutilizing the header pursuant to aspects of the invention;

FIGS. 40 and 42 are schematic diagrams of an embodiment for usingtriangulation of a plurality of repeaters to determine a position andfor using the determined position to filter traffic information pursuantto aspects of the invention;

FIGS. 41 and 43 are flow diagrams of an embodiment for usingtriangulation to determine a position and for using the determinedposition to filter traffic information pursuant to aspects of theinvention;

FIG. 44 is a flow diagram of an embodiment for allowing a user to scrollto a needed traffic information pursuant to aspects of the invention;

FIG. 45 is a flow diagram of an embodiment for filtering trafficinformation based on a plurality of parameters entered by a userpursuant to aspects of the invention;

FIG. 46 is a schematic diagram of an embodiment for reducing thebroadcast of redundant and/or static traffic information pursuant toaspects of the invention;

FIG. 47 is a flow diagram of an embodiment that provide an option for auser to avoid a traffic incident and/or congestion pursuant to aspectsof the invention;

FIGS. 48 a and 48 b illustrate an embodiment for avoiding a zigzag routepursuant to aspects of the invention;

FIG. 49 is a flow diagram of an embodiment that reduces zigzaggingpursuant to aspects of the invention; and

FIGS. 50, 51, 52, 53 a, and 53 b illustrate embodiments for calculatingand utilizing a distance threshold that provides a distance value atwhich it is likely that a traffic problem location that exists past thisdistance value from a current location of a vehicle will expire beforethe vehicle can reach the problem location pursuant to aspects of theinventions.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention is directed to a system and method forfacilitating the exchange of traffic information between a remotelocation and a vehicle. In particular, the present invention is directedto a system and method that includes a vehicle that exchanges trafficinformation with the remote location by way of one or more communicationnetworks in a manner that conserves bandwidth while providing sufficienttraffic information to the vehicle.

FIG. 1 a shows a first embodiment of a system for facilitating theexchange of information between a remote location 10 and a vehicle 12pursuant to aspects of the invention. The vehicle 12 includes anavigation device 14. Referring now also to FIG. 1 c, the navigationdevice 14 may include an output unit 21, a receiver unit 22, an inputunit 23, a position detection unit 25, a navigation memory unit 30, anavigation processor unit 26, and an RF transceiver unit 52 that are allin electrical communication with one another. The navigation memory unit30 includes at least a portion of a user profile and, in someembodiments, includes the entire user profile. In addition, thenavigation memory unit 30 includes a road map database portion and, insome embodiments, includes a disk reading unit for reading road mapinformation not built into the navigation device 14. As is provided ingreater detail below, the user profile and/or the road map databasestored in the memory 30 may be updated in the vehicle by way of theinput unit 23, which includes at least one of a keyboard, a touchsensitive display, and a microphone. The user profile and/or the roadmap database may also be updated by way of information received throughthe receiver unit 22 and/or the RF transceiver unit 52.

The receiver unit 22 receives information from the remote location 10and, in one embodiment, is in communication with the remote location byway of a one-to-many communication system. One-to-many communicationsystems include systems that can send information from one source to aplurality of receivers, such as a broadcast network 31. Broadcastnetworks include television, radio, and satellite networks. Referringnow to FIG. 1 b, in one embodiment, the broadcast network 31 is the XMRadio satellite network 40, which comprises broadcast towers 42,satellite servers (not shown), and satellites 43. The broadcast towers42 transmit information to the satellites 43, which bounce theinformation back down to the receiver unit 22 of the navigation device14.

Referring now back to FIG. 1 a, the information received by the receiver22 may be processed by the navigation processor unit 26. The processedinformation may then be displayed by way of the output unit 21, whichincludes at least one of a display and a speaker. In one embodiment, thereceiver unit 22, the navigation processor unit 26 and the output unit21 are provided access to only subsets of the received broadcastinformation based on user preferences and/or traffic informationdemands. The user preferences, as well as user identity information andtraffic-related information, can be part of the user profile.

The position detection unit 25 may include a GPS receiver thatcommunicates with a plurality of GPS satellites (separate from the XMsatellites) to determine the position of the vehicle 12. For example,the GPS receiver searches for and collects GPS information (or signals)broadcast from four or more GPS satellites that are in view of the GPSreceiver. Next, using the time interval between the broadcast time andreception time of each broadcast signal, the GPS receiver calculates thedistance between the GPS receiver and each of the four or more GPSsatellites. These distance measurements, along with the position andtime information received in the broadcast signals, allow the GPSreceiver to calculate the geographic position of the vehicle 12.

In the embodiment shown in FIG. 1 a, the mobile unit 18 is used toreceive and transmit information from and to the remote location 10;and, in an alternate embodiment shown in FIG. 2, an RF transceiver 252is used to receive and transmit information from and to the remotelocation 210. The mobile unit 18 may be a wireless phone or any otherdevice that communicates with other devices by way of the wirelesscommunication network 46. As shown in FIG. 1 c, the mobile unit 100 ofthe present invention includes a wireless receiver 32, a wirelesstransmitter 34, a mobile unit processor 40, and an RF transceiver unit54 that are in communication with one another. The mobile unit 18 is intwo-way communication with the remote location 10 by way of the receiver32, the transmitter 34, and the wireless communication network 46, whichcomprises numerous base stations. In one embodiment, information istransmitted from or to the vehicle or remote location over a highbandwidth GPRS/1XRTT channel of the wireless communication network 46.If the high bandwidth channel is unavailable, a low bandwidth DTMFchannel is used. The receiver 32 receives information from the remotelocation 10, and the transmitter 34 transmits information to the remotelocation 10. In other embodiments described below in greater detail, thetransmitter 34 also transmits information to suppliers of traffic orother information 48, 50.

In one embodiment, the information received from and transmitted to theremote location 10 by way of the mobile unit 18 is accessed by the userthrough the navigation device 14, which is in communication with themobile unit 18. The mobile unit 18 may be embedded in the vehicle 12 andbe in communication with the navigation device 14 by, for example, acable (not shown).

In another embodiment, the navigation device 14 and mobile unit 18 arein communication with one another by way of RF transceiver units 54 and52. Both the navigation device 14 and the mobile unit 18 include RFtransceiver units 52, 54, which, in one embodiment, comply with theBluetooth® wireless data communication format. The RF transceiver units52, 54 allow the navigation device 14 and the mobile unit 18 tocommunicate with one another. In other embodiments not shown, thereceiver 32 and transmitter 14 of the mobile unit 18 and the receiverunit 20 of the navigation device 14 allow the navigation device 14 andmobile unit 18 to communicate with one another. In yet otherembodiments, there may be an RF transceiver that is separate from thenavigation device 14 and the mobile unit 18 and that allows thenavigation device 14 and mobile unit 18 to communicate with one another.

In the alternate embodiment shown in FIG. 2, the navigation device 214transmits and receives information to and from the remote location 210by way of the RF transceiver 252, access points 270, 272, and gateways274, 276 that are in communication with the network 262. In oneembodiment, the RF transceiver 252 and the access points 270, 272 arecompliant with the IEEE 802.11 specification, and such transceivers andaccess points include Wi-Fi®-certified equipment. The access points 270,272 are typically in communication with the gateways 274, 276 by way ofa cable, and the gateways are in communication with the remote location210 by way of the network 262. The access points 270, 272 are incommunication with the RF transceiver 252 and have a limited range overwhich they can communicate with the RF transceiver 252. Thus, it ispreferable that there be numerous access points 270, 272 positioned sothat the distance between the access points and the areas through whicha vehicle 12 might pass is less than or equal to the limited range ofthe access points. When the access points 270, 272 are so positioned,the RF transceiver 252 effectively exchanges information with the accesspoints 270, 272 and, thus, the remote location 210.

Note that in the alternate embodiment of FIG. 2, the navigation device214 also includes input and output units, a receiver unit, a memoryunit, and a processor unit, none of which are shown. The components ofthe alternate navigation device embodiment 214 have the samefunctionality as do the components of the navigation device 14 of thefirst embodiment.

The remote location 10, 210 includes a remote server 44, 244, a remotetransmitter 56, 256 and receiver 58, 258, and a remote memory 60, 260that are in communication with one another. As provided above, in thefirst embodiment, the remote transmitter and receiver 56, 58 communicatewith the navigation device 14 and mobile unit 100 by way of thebroadcast 31 and wireless 46 communication networks, respectively. Inthe alternate embodiment, the remote transmitter and receiver 256, 258communicate with the navigation device 214, including the RF transceiver252, by way of the broadcast communication network 231 and a network262. The remote location 10, 210 is also in communication with suppliersof traffic and/or other information 48, 50, 248, 250 such as governmenttraffic information suppliers, private traffic information suppliers,and users of other vehicles, by way of the network 62, 262.

In both the first and alternate embodiments shown in FIGS. 1 and 2, thenetwork 62, 262 is typically a wide area network (WAN) such as theInternet. In other embodiments, some of the information suppliers 48,50, 248, 250, such as the government and private traffic informationsuppliers, may be in communication with the remote location 10, 210 byway of a local area network (LAN), while other information providers 48,50, 248, 250 such as the vehicle users, are in communication with theremote location by way of the Internet. In yet other embodiments, the RFtransceiver 252 is in communication with the remote location 210 and/orthe information providers 248, 250 by way of a network 262 that is anLAN. In these other embodiments, the LAN 262 is compliant with the IEEE802.3 specification or is an Ethernet network.

As provided in greater detail below, the information suppliers 48, 50,248, 250 may transmit updated user profiles and traffic-relatedinformation to the remote location 10, 210. A plurality of user profilesare in a user profile database, which, along with traffic-relatedinformation, is stored in the remote memory 60, 260. The updated userprofiles and new traffic-related information are transmitted from theremote location 10, 210 to the navigation device 14, 214 by way of thebroadcast network 31, 231. In other embodiments, the new traffic-relatedinformation and updated user profiles may be transmitted to the vehicles12, 212 by way of the wireless network 46 or the network 262. At thevehicle, the user profile stored in the memory 30 of the navigationdevice 14 is updated, and the vehicle-related information is madeaccessible to the user by way of the output unit 26 of the navigationdevice 14. In other embodiments, the information providers maycommunicate directly with the mobile unit 18 or RF transceiver 252 byway of the wireless communication network 46 or the network 262.

FIG. 3 a shows an embodiment for ensuring quality and reliability oftraffic information provided to the navigation device 14, 214 pursuantto aspects of the invention. The embodiment uses the navigation device14, 214 (including its position detection unit 24) on the vehicle 12,212 to determine vehicle location and to detect sensor error or errorson a road segment/lane (e.g., speed sensors on a freeway lane/segment).The embodiment then uses the wireless network 46 or the network 262 tocommunicate the position determination and the error detection data fromthe navigation device 14, 214 to the remote location 10, 610 and/ortraffic information suppliers 48, 248 in an effort to refine the trafficinformation provided. At step 300, the navigation device 14, 214 usesits position detection unit 24 to determine vehicle location and speeddata. The vehicle's location and speed data is then communicated overthe wireless communication network 46 or the network 262 to the remotelocation 10, 210.

At step 305, the remote location 14, 214, via its remote server orservers 44, 244, processes and passes the vehicle location and speeddata to traffic information supplier or suppliers 48, 248. The data fromthe remote location is transmitted over the network 62 or the network262 to the traffic information supplier or suppliers 48, 248. In oneembodiment, the data is processed at the remote location 14, 214 byfiltering the information based on predetermined criteria andtranslating the information into a format acceptable to the trafficinformation supplier or suppliers 48, 248. At step 310, the transmittedvehicle location and vehicle speed data is processed at a database ofthe traffic information supplier or suppliers 48, 248. At step 315, thevehicle's location and speed data (i.e., the back channel data) iscompared with sensor data from a speed sensor on a lane of a freeway todetermine the difference between the vehicle speed data and the sensorspeed data. The location of the speed sensor corresponds to the locationof the vehicle where the vehicle's location and speed data was detected.At step 320, a quantized differential action scheme based on a range ofthe speed differences between the vehicle speed data and the sensorspeed data is used to determine action items. FIG. 3 shows that adifference of zero (0) to ten (10) mph is acceptable, a difference ofeleven (11) to fifteen (15) mph triggers an automatic alert to check thespeed difference and speed sensor, a difference of sixteen (16) totwenty (20) mph triggers an automatic alert to monitor the speed of thesensor, a difference of twenty-one (21) to twenty-five (25) mph triggersan automatic replacement alert, and a difference of twenty-six (26) ormore mph triggers automatic replacement or maintenance of the sensor.Once the appropriate action item has been determined, at step 325, therefined traffic information data (e.g., with corrected speed sensordata) is broadcast to a plurality of vehicles that may include vehicle12, 212, by way of the broadcast network 31, 231.

The above-described mechanisms and process for ensuring quality andreliability of traffic information are for exemplary purposes only, andthe invention is not limited thereby. For example, FIG. 3 b shows analternate embodiment that uses a quantized percentage differentialmethod. In this method, as shown in steps 330 and 335, a percentagedifference between the vehicle speed data and the speed sensor data isused to select an action item from a plurality of action items ratherthan using the actual differences between the vehicle speed data and thespeed sensor data. That is, at step 330, the vehicle's location andspeed data (i.e., the back channel data) is compared with sensor datafrom a speed sensor on a lane of a freeway to determine a percentage (%)difference in speed of the vehicle speed data and the sensor speed data.At step 335, a percentage quantized differential action scheme based ona range of the percentages of difference of the sensor speed data to theback channel data is used to select an action from a plurality of actionitems to be taken. FIG. 3 b shows that a difference of less than 20% ofthe sensor speed data to the back channel data is acceptable, a 21% to30% difference triggers an automatic alert to check the speed sensor, a31% to 40% difference triggers an automatic alert to monitor the speedof the sensor, a 41% to 50% difference triggers an automatic replacementalert, and a greater than 50% difference triggers the automaticreplacement or maintenance of the sensor.

Note that, in the alternate embodiment of FIG. 3 b, the embodiment alsoincludes the transmission and processing steps 300, 305, 310, and 325described above for FIG. 3 a. In addition, the steps of FIG. 3 b use thesame devices, units, and/or components as the embodiment shown in FIG. 3a. Moreover, those skilled in the art will appreciate that there areother ways to process the traffic-related information to ensure qualityand reliability.

FIG. 4 shows an embodiment for coordinating traffic signals pursuant toaspects of the invention. The embodiment uses the navigation device'sposition determination unit (e.g., the GPS) and back channelcapabilities (e.g., the wireless communication network 46 or the network262). The embodiment includes a navigation device (e.g., a device 14,214 shown in FIGS. 1 a, 2) having a position detection unit (e.g., unit24 shown in FIG. 1 c). The navigation device is located on a vehicle 412and is used to determine the location and speed of the vehicle 412 andto coordinate traffic signals 445 (e.g., freeway off-ramp signals). Morespecifically, the embodiment uses back channel communication 446 tocommunicate the speed and location of the vehicle 412 detected from thenavigation device (e.g., 14, 214) to a remote location 410. The remotelocation 410 then transmits the speed and location of the vehicle to atraffic information supplier 448 that passes this information to asignal control center 450 (e.g., a city traffic center). The signalcontrol center then adjusts, coordinates, and manages the trafficsignals 445 based on the information from the traffic informationsupplier 448.

In general, according to FIG. 4, the embodiment provides a method forcoordinating traffic signals, as diagrammed in FIG. 5. At step 505, themethod receives probe and flow sensor data (e.g., data on the positionof the vehicle, the speed of the vehicle, and the average speed ofvehicles on a lane of a road). At step 510, the method displays theflow-sensor data. At step 515, the difference in speed between variouslanes 460 of a roadway (e.g., a freeway) and the location of the vehicle412 are determined. If the difference in speed between lanes 460 is lessthen twenty (20) mph and the vehicle 412 is within an amount of milesfrom the off-ramp (e.g., within a predetermined amount miles of theoff-ramp), the signal length or signal timing for the traffic signals455 is increased pursuant to step 520 and the chart shown below.Distance from off-ramp Increase signal length >0.25 miles 10%  >0.5miles 15% >0.75 miles 20%  >1.0 miles 30% >1.25 miles 40%  >1.5 miles50%

Those skilled in the art will appreciate that the above method forcoordinating traffic signals (e.g., by using lane averaging to clearfreeway off-ramps) alleviates problems that occur when traffic-flowsensors are not available or not accurate and reduces the potential foraccidents. It should be appreciated that the above-described mechanismsand process for coordinating traffic signals are for exemplary purposesonly and that the invention is not limited thereby.

FIG. 6 shows an embodiment for providing automated and personalizedtraffic information so that a user of a navigation device 614 located ona vehicle 612 does not have to wait for traffic information. Theembodiment allows the user of the navigation device 614 to preset itscommute preferences (e.g., 7 a.m. home to work; 5 p.m. work to home) sothat traffic information from the traffic information supplier 648and/or remote location 610 can be pre-provided or pre-broadcast to thenavigation device 614 via a broadcast network 631. More specifically,rather than require the user to input its destination point in thenavigation device 614, the present embodiment allows the user to storean address/destination in a memory unit (e.g., unit 30 in FIG. 1 c) ofthe navigation device 614. In addition, rather than requiring the userto wait for the traffic information to be updated by the trafficinformation supplier 648 and for the user route to be calculated by thenavigation device 614, the present embodiment allows the user to set itscommute preferences in an owner link 615 (e.g., a database) located inthe remote location 610 so that traffic information can be pre-broadcastto the navigation device 614. That is, the present embodiment allows auser to (1) set an address/destination in a memory unit (e.g., unit 30in FIG. 1 c) of the navigation device 614 and (2) set its commutepreferences in an owner link 615 (e.g., a database) via the remotelocation 610 so that traffic information can be pre-broadcast to thenavigation device 614.

The above-described mechanisms and process for providing automated andpersonalized traffic reports are for exemplary purposes only and theinvention is not limited thereby. For example, FIG. 7 shows an alternateembodiment that automatically stores historical data of the user todetermine when traffic information should be pre-provided. In thisembodiment, based on historical commute patterns, the embodiment usesback channel communication 746 to store start times and addresses on aremote location 710 such that no address input is required. Thisembodiment automates an owner link function (e.g., 615 on FIG. 6) fortraffic information by storing the pertinent commute information tomemory with an internal clock (e.g., a GPS internal clock) of thenavigation device 714 to determine when to gather traffic informationdata and begin route calculations. The gathering of the trafficinformation data and the calculation of routes are performed before theuser enters the vehicle 712 with the navigation device 714. It should beappreciated by those skilled in the art that the above method furtherincreases the convenience for providing automated and personalizedtraffic reports as compared to the method and system described withrespect to FIG. 6.

FIG. 8 shows a method for filtering traffic information. Trafficinformation broadcast from a traffic information supplier to a fifteen(15) mile radius 800 from a user's location is filtered to expeditetraffic calculation. This filtering embodiment saves on processinghardware and/or a bandwidth requirement of a navigation device and/orthe traffic supplier. More specifically, the traffic informationsupplier broadcasts nationwide traffic information into twenty (20)smaller metropolitan area-wide information (or metros). The presentfiltering embodiment uses position information (e.g., GPS locationinformation) at the start-up of the navigation device or from the memoryof the navigation device if the navigation device is unable to acquireposition information not only to filter the needed metro from thenationwide traffic information but also to filter down the needed metroto specific user applicable area. That is, in the present embodiment,each traffic communication packet between the navigation device and itstraffic supplier includes information on metro location and filteringinformation for further filtering the traffic information to a fifteen(15) mile radius from a user's location.

In general, according to FIG. 8, the embodiment provides a method forreal time filtering of traffic updates, as diagrammed in FIG. 9 a. Atstep 900, the method determines the location of the navigation device(e.g., a GPS location). At step 905, the method receives trafficinformation (e.g., U.S. traffic information). At step 910, the methoddetermines whether the traffic information is within a predeterminedradius of the navigation device or fifteen (15) mile radius of thenavigation device. If the traffic information is within thepredetermined radius, the navigation device then calculates a route forthe user of the navigation device using the filtered traffic informationat step 915. However, if the traffic information is not within thepredetermined radius, then the traffic information is discarded at step920.

The above-described method for real time traffic update filtering arefor exemplary purposes only and the invention is not limited thereby.For example, FIG. 9 b shows an alternate method that uses GPS locationinformation to automatically filter traffic information based on alocation of the navigation device. However, if there is still too muchtraffic information due to additional congestion in a specific metro forthe navigation device to display/calculate effectively, the method usesdecreasing radius(es) to display/calculate information in the specificmetro. In this method, as shown in step 900, a location of a navigationdevice (e.g., a GPS location) is determined. At step 907, the methodreceives traffic information for a specific metro. At step 930, themethod determines whether the traffic information is approaching amemory capacity level (e.g., a 90% memory capacity level) of thenavigation device. If the traffic information is approaching the memorycapacity, the method then selects a step-to-step criteria for filteringthe traffic information pursuant to steps 935, 940, and 945 and thechart shown below. Steps 935, 940, and 945 are repeated until the memorycapacity of the navigation device is below the predetermined capacitylevel. The method then move to step 950 to calculate a route using thefiltered traffic information. The calculated result is displayed at step955. Step Criteria 1 Entire Metro incident and flow (i/f info) 2distance = 15 miles (i/f info) 3 distance = 10 mi (i/f info) 4 Distance= 7.5 mi (i/f info) 5 Dist = 5 mi (i/f info)

FIG. 9 c shows another method for filtering traffic information. Thismethod monitors memory capacity to maximize an available metro trafficinformation and to increase the traffic information available forcalculation by a navigation device. As shown in step 900, the methoddetermines a location of a navigation device (e.g., a GPS location). Atstep 907, the method receives traffic information for a specific metro.At step 960, the method determines whether the traffic information isapproaching a memory capacity level (e.g., a 90% memory capacity level)of the navigation device. If the traffic information is not approachingthe memory capacity, the method then selects a step-to-step criteria forreverse-filtering (or increasing) the available traffic informationpursuant to steps 960, 965, 970, 975, and 980 and the chart shown below.Steps 960, 965, 970, 975, and 980 are repeated until the memory capacityof the navigation device is approaching the predetermined capacitylevel. The method then calculates a route using the reverse-filteredtraffic information at step 985 and displays the calculated route atstep 990. Step Criteria 1 distance = 15 miles (i/f info) 2 distance = 25miles (i/f info) 3 Entire Metro incident and flow (i/f info) 4 Metro +adjacent Metro(s)

FIG. 10 shows a method for providing weight factors and thresholdprioritization when a broadcast limit (e.g., an XM bandwidth limit) isclose to being reached. The method is utilized with a broadcast network(e.g., an XM broadcast network) that broadcasts traffic informationinitially, for example, to twenty metropolitan areas (metros). Themethod prioritizes traffic information and maintains maximum bandwidthavailability by assigning weight factors to each reported incident andbroadcasting the traffic information based on the assigned weightfactors. The assigning of the weight factors and the broadcasting oftraffic information based on these factors would occur only when acertain preset broadcast threshold is met (e.g., 80% capacity of thenetwork has been reached). At step 1005 of FIG. 10, a central processorat a remote location (e.g., 10 in FIG. 1 a) and/or at a navigationdevice (e.g., 12 in FIG. 1 a) determines if a network broadcastthreshold has been met (e.g., 80% of the capacity of the broadcastnetwork). If the broadcast threshold has been met, weight factors areassigned to each piece of the traffic information (e.g., trafficinformation packets) based on the subject matter of the trafficinformation pursuant to step 1015 and the chart shown below. ItemDescription Weight Factor Severity Accident 10 Incident 9 Construction 8Weather 8 Location within city metro 10 outside city metro 8 DateWeekday 10 Weekend 9 Holiday 8 Time 6-9 AM 10 9-4 AM 6 4-7 PM 10 7 PM-6AM 2 Weight factor Ambulance responding 9 Fatality 10  >30 min. delay 2  >1 hr. delay 4 >1.5 hr. delay 6   >2 hr. delay 8 >2.5 hr. delay 10

Those skilled in the art will appreciate that the above method for themanagement of traffic information and broadcast bandwidth provides aproactive approach to ensure most critical traffic information orincidents are reported while still maintaining bandwidth requirements.It should also be appreciated that the above-described mechanisms andprocess for bandwidth management are for exemplary purposes only andthat the invention is not limited thereby.

FIG. 11 shows an embodiment of a navigation device that initiates arecalculation of a route 1100 when there is a upcoming turn 1105 toanticipate a user of the navigation device missing the turn 1105. Forexample, referring now also to FIG. 12, the navigation device makes anassumption that a vehicle's starting point 1214 is somewhere ahead ofits actual starting point 1212, not on the route 1200, to anticipate auser of the navigation device missing a turn 1205. In the presentcontext, recalculation refers to all possible routes that the user maytake when an error occurs (e.g., user should go left but goes right).Recalculation can also be referred to as pre-calculation or erroranticipating calculation. Referring now back to FIG. 11, therecalculations can be made at variable times 1110 a 1110 b, 1110 c, 1110d.

FIG. 13 shows an embodiment of a navigation device that performs a routecalculation using traffic information broadcast from a remote locationand/or a traffic information supplier. For example, referring now toFIG. 13, the traffic information updates may be provided to thenavigation device every one (1) minute or five (5) minutes, and thenavigation device calculates a new route with every traffic informationupdate for better route guidance. That is, referring now also to FIG.14, once traffic information has been completely refreshed or updated, aroute calculation is triggered using a vehicle's current position 1412as the starting point.

FIG. 15 shows an embodiment of a method that uses every trafficinformation update to act as a trigger for calculation and recalculation(i.e., anticipation of a user error). At step 1500, a navigation deviceis set at a route guidance mode. At step 1505, the navigation devicedetermines whether to recalculate (i.e., pre-calculate) a new route. Forexample, the navigation device anticipates a user error as shown in FIG.12 and determines that a new route (e.g., one based on an anticipateduser error) should be calculated. If the navigation device recalculatesthe new route, the new route is displayed to a user of the navigationdevice at step 1510, and the method moves to step 1515. If thenavigation device does not recalculate the new route, the method movesdirectly to step 1515. At step 1515, the navigation device determineswhether a traffic information update has been provided to the navigationdevice. If the traffic information update has not been provided, themethod moves to step 1500. If the traffic information update has beenprovided, the navigation device calculates a new alternative route withthe updated traffic information at step 1520, and the method moves tostep 1525. At step 1525, the method determines whether the alternativeroute is better (e.g., whether it has a shorter estimated travel time)than the route previously displayed to the user. If the alternativeroute is better, the navigation device displays the alternative routewith the traffic information at step 1530, and then moves to step 1500.

The above-described mechanisms and process for route calculation andrecalculation using traffic information are for exemplary purposes only,and the invention is not limited thereby. For example, FIG. 16 shows anembodiment of a method that uses every traffic information update to actas a trigger for recalculation but does not recalculate to anticipateuser error. The embodiment is designed to reduce processing requirementsat the navigation device. That is, at step 1600, a navigation device isset at a route guidance mode, and the method moves immediately to step1605. At step 1605, the navigation device determines whether a trafficinformation update has been provided to the navigation device. If thetraffic information update has not been provided, the method moves tostep 1600. If the traffic information update has been provided, thenavigation device calculates a new alternative route with the updatedtraffic information at step 1610, and the method moves to step 1615. Atstep 1615, the method determines whether the alternative route is better(e.g., whether it has a shorter estimated travel time) than the routepreviously displayed to the user. If the alternative route is better,the navigation device displays the alternative route with the trafficinformation at step 1620, and then moves to step 1600.

FIG. 17 shows an embodiment of a method that uses streaming (non-staticor constantly changing) traffic information data and an internalprocessing clock to trigger route calculation at fixed and/or variabletime intervals. At step 1700, a navigation device is set at a routeguidance mode. At step 1705, the navigation device determines whether apredetermined amount of time (e.g., one minute) has elapsed using aninternal processing clock (e.g., one located in a processor unit and/ora position determination unit of the navigation device). If thepredetermined amount of time has not elapsed, the method moves to step1700. If the predetermined amount of time has elapsed, the navigationdevice calculates a new alternative route with the updated trafficinformation at step 1710, and the method moves to step 1715. At step1715, the method determines whether the alternative route is better(e.g., whether it has a shorter estimated travel time) than the routepreviously displayed to the user. If the alternative route is better,the navigation device displays the alternative route with the trafficinformation at step 1720 and then moves to step 1700.

FIG. 18 shows an embodiment of a method that waits for a recalculation(i.e., an anticipation of a user error) to finish and then calculates anew alternate route with traffic information to determine the bestroute. That is, in the method shown in FIG. 18, the recalculation(without traffic information) always takes precedence over thecalculation with traffic information. In addition, it should beappreciated that the steps shown in FIG. 18 are similar to those shownfor FIG. 15 with the exception of additional step 1512 (located betweenthe recalculation step 1510 and the traffic information updatedetermination step 1515) that determines whether the recalculation (atstep 1510) has been completed.

FIG. 19 shows an embodiment of a method that stores the trafficinformation data when a navigation device is recalculating a routeand/or receiving a traffic information update. After the recalculationis completed, the method then resumes route calculation with the trafficinformation data. In addition, the method of FIG. 19 takes the previoustraffic information calculated route and compares it with the newrecalculated route (e.g., to determine the best route) when the methodis between traffic information updates. That is, the method uses its oldtraffic information until new traffic information has been completelyprovided to the navigation device.

FIGS. 20 and 20 a show an embodiment of a method that streams trafficinformation data to provide users with the most up to date information.In addition, depending on the time of day, the method varies the trafficinformation update triggers such that, at peak commute times, therecalculation (and calculation) triggers are increased and, at off peakcommute times, the triggers are decreased. Those skilled in the art willappreciate that the method of FIGS. 20 and 20 a minimizes the amount oftime needed for updated traffic information to trigger a new calculationand provides updated traffic information based on a need use basis.

In addition, FIG. 20 shows a method for increasing and decreasingamounts and/or numbers of broadcast traffic information (e.g., via an XMnetwork) based on commute times. More specifically, the method variesthe broadcast of traffic information data based on commute times in eachtime zone, as shown in the following chart. Pacific Mountain CentralEastern Broadcast Broadcast Broadcast Broadcast Time rate rate Time rateTime rate  1:00 AM 5 min  2:00 AM 5 min  3:00 AM 5 min  4:00 AM 5 min 2:00 AM 5 min  3:00 AM 5 min  4:00 AM 5 min  5:00 AM 5 min  3:00 AM 5min  4:00 AM 5 min  5:00 AM 5 min  6:00 AM 30 sec  4:00 AM 5 min  5:00AM 5 min  6:00 AM 30 sec  7:00 AM 30 sec  5:00 AM 5 min  6:00 AM 30 sec 7:00 AM 30 sec  8:00 AM 30 sec  6:00 AM 30 sec  7:00 AM 30 sec  8:00 AM30 sec  9:00 AM 30 sec  7:00 AM 30 sec  8:00 AM 30 sec  9:00 AM 30 sec10:00 AM 5 min  8:00 AM 30 sec  9:00 AM 30 sec 10:00 AM 5 min 11:00 AM 5min  9:00 AM 30 sec 10:00 AM 5 min 11:00 AM 5 min 12:00 PM 5 min 10:00AM 5 min 11:00 AM 5 min 12:00 PM 5 min  1:00 PM 5 min 11:00 AM 5 min12:00 PM 5 min  1:00 PM 5 min  2:00 PM 5 min 12:00 PM 5 min  1:00 PM 5min  2:00 PM 5 min  3:00 PM 5 min  1:00 PM 5 min  2:00 PM 5 min  3:00 PM5 min  4:00 PM 30 sec  2:00 PM 5 min  3:00 PM 5 min  4:00 PM 30 sec 5:00 PM 30 sec  3:00 PM 5 min  4:00 PM 30 sec  5:00 PM 30 sec  6:00 PM30 sec  4:00 PM 30 sec  5:00 PM 30 sec  6:00 PM 30 sec  7:00 PM 30 sec 5:00 PM 30 sec  6:00 PM 30 sec  7:00 PM 30 sec  8:00 PM 5 min  6:00 PM30 sec  7:00 PM 30 sec  8:00 PM 5 min  9:00 PM 5 min  7:00 PM 30 sec 8:00 PM 5 min  9:00 PM 5 min 10:00 PM 5 min  8:00 PM 5 min  9:00 PM 5min 10:00 PM 5 min 11:00 PM 5 min  9:00 PM 5 min 10:00 PM 5 min 11:00 PM5 min 12:00 AM 5 min 10:00 PM 5 min 11:00 PM 5 min 12:00 AM 5 min  1:00AM 5 min 11:00 PM 5 min 12:00 AM 5 min  1:00 AM 5 min  2:00 AM 5 min12:00 AM 5 min  1:00 AM 5 min  2:00 AM 5 min  3:00 AM 5 min

In addition, if certain metros have more congestions, user demands,vehicles, etc., the above broadcast method can vary the broadcast timeor rate in the specific metro as shown in the following chart. BroadcastMetro time rate 6:00 to 9:00 AM Every 30 sec. 9:01 AM to 3:59 PM Every 5min. 4:00 PM to 7:00 PM Every 30 sec. 7:01 PM to 5:59 AM Every 5 min.

Those skilled in the art will appreciate that the above method forproviding a variable broadcast rate allows a navigation device toreceive quicker and more accurate broadcast traffic information. Itshould also be appreciated that the above-described mechanisms andprocesses for variable broadcasting are for exemplary purposes only, andthe invention is not limited thereby.

FIG. 21 shows an embodiment of a display system that, when a user isrerouted by a navigation device, displays the new route's mileage 2100and/or estimated time of arrival (ETA) 2105 and/or differences comparedto the original route 2110 so that the user can make a direct comparisonof the two routes. More specifically, the present display system allowsthe navigation device using broadcast traffic information to conveyreasons why a new route using the traffic information has beencalculated, selected, and/or displayed to the user (e.g., because it hasa shorter travel time even if the actual distance may be longer). Itshould also be appreciated that the above-described display system isfor exemplary purposes only and that the invention is not limitedthereby.

In general there are two types of traffic information: traffic flowinformation and traffic incident information. Ideally, both types ofinformation should be available to a navigation device (e.g. 14 inFIG. 1) so that the navigation device can use the incident informationto avoid a traffic incident and the flow information to avoid trafficcongestion. To illustrate a particular problem that an embodiment of thepresent invention addresses, FIG. 22 a shows a case where the trafficincident information is available but the flow information is notavailable. In this case, a navigation device may determine that a route2200 b is free flowing and direct the users to that route 2200 b insteadof route 2200 a or route 2200 c. However, as shown in FIG. 22 b, route2200 b is actually congested and route 2200 c with an reported incidentmay actually be better (i.e., a faster route).

In general, according to problems illustrated in FIGS. 22 a and 22 b,the embodiment of the present invention provides a method for combiningactual and historical traffic information to predict traffic congestion,as diagrammed in FIG. 23. At step 2300, a navigation device (e.g., thenavigation device 14 shown in FIG. 1 a) calculates a route using trafficinformation that has been provided. At step 2305, the navigation devicedetermines if the route calculation has the required traffic flowinformation. If the required traffic flow information is available, thenavigation device then calculates the best route and displays this routeto a user of the navigation device at step 2330. If the required trafficflow information is not available or cannot be provided, the navigationdevice contacts a database (e.g., a database in the remote location 10shown in FIG. 1 a) via its back-channel capabilities to receivehistorical traffic flow information at step 2310. The historical trafficflow information is then broadcast over a broadcast communicationnetwork (e.g., 31 in FIG. 1 a) to the navigation device at step 2320. Atstep 2325, the navigation device then calculates the best route anddisplays this route to a user of the navigation device at step 2330.Again, it should be appreciated that the above-described mechanisms andprocess for combining actual and historical traffic information are forexemplary purposes only and that the invention is not limited thereby.

FIG. 24 shows an embodiment for providing a time stamp to trafficincident information and for using the time stamp to determine a routefor calculation by a navigation device. The embodiment can be applicableto a case when traffic flow information is not available, for example,due to sensor not available, damaged, malfunctioning, etc. Theembodiment can also be applicable to a case where traffic informationthat is provided does not report details of the extent of the congestion(e.g., from where to where is traffic congested) and/or a case wheredelays occur in providing incident details other than a location of anincident. Specifically, if traffic flow information is not available,traffic incident information with extent of where to where trafficcongestion is occurring is not available, and/or there are equal numbersof traffic incidents to avoid, the embodiment provides a method thattime stamps traffic incident information (having a location of theincident) and calculates a route by avoiding latest traffic incidents.At step 2400, the method begins a route calculation process. At step2405, the route calculation process determines if traffic flowinformation or if traffic incident information with extent information(e.g., extent information from where to where is traffic congested) isavailable. If the determined traffic information is available, themethod moves to step 2412 to perform a route calculation based on thetraffic information. The calculated route is then displayed at step2420. If the traffic flow information and the traffic incidentinformation with extent details are not available, the method moves to2410 to determine a time from traffic incident reported for eachreported traffic incident. The method, at step 2415, then performs aroute calculation based on a route having the traffic incidents with thegreatest total time (i.e., by avoiding the latest traffic incidents).The calculated route (not having the latest traffic incidents) is thendisplayed at step 2420.

Those skilled in the art will appreciate that the above method forproviding a time stamp to traffic incident information and for using thetime stamp to determine a route calculation alleviates problems thatoccur when only basic traffic incident information is available andprovides a user of a navigation device (e.g. a device 14, 214 shown inFIGS. 1 a, 2) with a way to automatically avoid traffic incidents basedon a timer-based incident avoidance scheme. It should be appreciatedthat the above-described mechanisms and process for route calculationsbased on an automatic timer based incident avoidance scheme are forexemplary purposes only and the invention is not limited thereby.

Referring now back to FIG. 8 and FIGS. 9 a to 9 c, the trafficinformation supplier broadcasts nationwide traffic information intotwenty (20) smaller metropolitan area-wide information (or metros) sothat embodiments of the present invention can use position information(e.g., GPS location information) to filter the needed trafficinformation. However, not all vehicles have GPS navigation systems,and/or receive GPS signals to identify their specific geographiclocation, and triangulation methodology may not be reliable and/oravailable due to repeater locations and/or building interference.Accordingly, referring now to FIG. 25, an embodiment of the inventionprovides a reliable method for filtering traffic updates without theneed of GPS navigation systems, GPS signals, repeaters, and/or repeatersignals. The embodiment provides a method for a user on a vehicle 2512to specify its home address and applicable metro location via an ownerlink 2515 (e.g., a website of the owner link 2515) so that a specifictraffic information can be received by the vehicle 2512.

Specifically, the embodiment of FIG. 25 provides a method that allows auser to manually enter a metro location, as diagrammed in FIG. 26. Atstep 2600, a user registers (or specifies) its home address andapplicable metro location via an owner link 2515. At step 2605, specifictraffic information for various regions (or metros) are broadcasted. Atstep 2610, the method determines whether a specific part of thebroadcasted traffic information is in a user-specified metro. If thespecific part of the broadcasted traffic information is in theuser-specified metro, the method then displays (or calculates a routefor the user via a navigation device) using the filtered trafficinformation at step 2620. However, if the specific part of the trafficinformation is not in the user-specified metro, then the specific partof the information is discarded at step 2615.

The above-described method for real time traffic filtering is forexemplary purposes only and the invention is not limited thereby. Forexample, FIG. 27 shows an embodiment that allows a user to manuallyenter its metro location via a menu on a radio of a vehicle 2712. Asdiagrammed in FIG. 28 a, a method of FIG. 27 begins with a userinputting its applicable metro via a control on a radio at step 2800. Atstep 2805, the radio of the invention interfaces with broadcastedtraffic information to filter the traffic information. At step 2810, themethod determines whether a specific part of the broadcasted trafficinformation is in a user-specified metro. If the specific part of thebroadcasted traffic information is in the user-specified metro, themethod then displays (or calculates a route for the user via anavigation device) using the filtered traffic information at step 2820.However, if the specific part of the traffic information is not in theuser-specified metro, then the specific part of the information isdiscarded at step 2815.

FIG. 28 b shows another embodiment of a method for filtering trafficinformation. This embodiment uses a user's FM radio station presetsand/or radio station settings on a radio of a vehicle 2712 toautomatically receive and/or filter applicable metro trafficinformation. As envisioned, the user can also have the option ofinputting its specific location manually via the radio. Morespecifically, the method of FIG. 28 b receives traffic information(e.g., U.S. traffic information) at step 2830. At step 2805, the methoddetermines if a radio of the vehicle 2712 is powered on. If the radio ison, the method then checks the user's current radio station with a tableor database 2845 to determine a location of the user's vehicle 2712 atstep 2840. If the radio is not on, the method then checks the user'spreset radio station with a table or database 2845 to determine alocation of the user's vehicle 2712 at step 2850. At step 2855, themethod determines whether it can use this automatically determinedlocation to determine a metro. If the metro can not be determined fromthe automatically determined location, the method then requests the userto manually specify a metro at step 2860. If the automaticallydetermined location can determine the metro, then the method determinesif traffic information for the automatically determined metro isavailable at step 2865. If the traffic information for the automaticallydetermined metro is not available, the method displays a “trafficinformation not applicable” indication to the user at step 2870. If thetraffic information for the automatically determined metro is available,the method then displays (or calculates a route for the user via anavigation device) using the automatically filtered traffic informationat step 2875.

FIG. 29 shows an embodiment for allowing a vehicle 2912 to automaticallyupdate via an internal clock of the vehicle 2912 to determine which timezone the vehicle 2912 is in and filters traffic information for thevehicle via the determined time zone. The embodiment broadcasts trafficinformation based on time zones (e.g., Pacific Time Zone, Mountain TimeZone, Central Time Zone, and Eastern Time Zone) 2920 and the vehicle2912 then filters 2935 out the non-matching time zone trafficinformation 2930.

More particularly, the embodiment of FIG. 29 provides a method thatautomatically filters traffic information based on time zones, asdiagrammed in FIG. 30. At step 3000, the method determines an internalclock setting of a vehicle 2912. At step 3005, the method receivestraffic information (e.g., U.S. traffic information). At step 3010, themethod determines whether a specific part of the received trafficinformation is in a user's or a vehicle's identified time zone. If thespecific part of the received traffic information is in the vehicle'sidentified time zone, the method then displays (or calculates a routefor the user via a navigation device) using the filtered trafficinformation at step 3015. However, if the specific part of the trafficinformation is not in the vehicle's identified time zone, then thespecific part of the information is discarded at step 3020.

FIG. 31 b shows an embodiment of a display system that displays trafficflow information 3100 and incident icons 3110 in the direction that auser is traveling. In addition, the system only displays the roadways orfreeways 3115 that the user would be driving on (i.e., if a vehicle isheading south, no northbound freeways will be displayed by the displaysystem). The above-described display systems allows the present displaysystem to convey information to a user in a clear, concise, andunderstandable manner without inundating the user with redundant,useless, and/or superfluous information as compared with the embodimentshown in FIG. 31 a.

FIGS. 32 a and 32 b show an embodiment of a display system that allows auser to use a cursor 3230 of a navigation device so that the user canclick on an actual roadway or freeway to get traffic flow information(and/or traffic incident information) 3200 on the roadway or freeway.

FIG. 33 shows an embodiment of a display system that, when a navigationdevice is providing a route guidance for a user, the display system ofthe navigation device provides a display icon 3310 on a road segment sothe user can visually see an upcoming incident. In addition, the displaysystem can also provides a turn-by-turn guidance display as shown in thefollowing chart. Route Miles Time Incidents on route  60 East 3 15 min

710 South 8 35 min

105 West 15 16 min 405 North 10 45 min

Those skilled in the art will appreciate that the above display systemsfor reducing non-essential traffic information alleviate problemsassociated with driver distractions. It should be appreciated that theabove-described mechanisms and processes for displaying trafficinformation are for exemplary purposes only and the invention is notlimited thereby.

FIG. 34 shows a window 3400 for displaying traffic information on atravel route 3405. The window 3400 is utilized by a navigation device(e.g., 14 in FIG. 1 a) after the navigation device detects a trafficincident on a route ahead. The navigation device displays the trafficincident details in the window 3400. The window 3400 appears or pops upon an output unit (e.g., 21 in FIG. 1 a) of the navigation device thatis displaying a map 3410 of the route ahead 3405. The window 3400informs a user of the navigation device of the traffic condition ahead.For example, the pop-up window 3400 informs the user of a location ofthe incident, distance from a current location of the user, incidentdetails, and/or possible effects on the route calculated by thenavigation device. The navigation device should also provide an option3415 to the user for requesting a new route that avoids the trafficincident. In addition, the navigation device should include an option3420 to keep the current route, an option 3422 to allow the user to readthe incident details, an option 3430 to go to the next traffic incidentinformation, and/or an option 3425 to display all details received foran incident.

More specifically, the embodiment of FIG. 34 provides a method, asdiagrammed in FIG. 35. At step 3500, the method calculates a route to adestination. At step 3505, the method receives traffic information(e.g., U.S. traffic information). At step 3510, the method determineswhether the received traffic information is referring to roads on thecalculated route to the destination. If the received traffic informationis not referring to the roads on the calculated route, the method movesback to step 3505. If the received traffic information is referring tothe roads on the calculated route, the method displays or shows thetraffic information to a user via a map 3410 of the route and a pop-upwindow 3400 at step 3515. At step 3520, the method determines whether tocalculate a new route for the destination to avoid a traffic incidentreported using the received traffic information. If the new route is tobe calculated, the method moves to step 3500 to calculate the new routeto the destination.

An embodiment of the invention reduces the bandwidth requirement forbroadcasting traffic information by utilizing a method that does notbroadcast free-flow traffic information. Thus, a user of this embodimentonly receives traffic information regarding known conditions affectingtraffic or only sees traffic information when there is a trafficproblem. More specifically, FIG. 36 b shows an embodiment of a displaysystem that displays only traffic information indicating trafficproblems and does not show free-flow traffic icons on the displaysystem, as compared with the embodiment shown in FIG. 36 a.

The above-described embodiment for simplifying a display is forexemplary purposes only and the invention is not limited thereby. Forexample, FIG. 37 shows an alternate embodiment that uses a method thatshows free-flow traffic icons by storing the locations of the flowsensors on another medium and cross-referencing with broadcast trafficinformation data. If no information is received regarding a particularsensor location, the method assumes free-flowing traffic and indicatesthat particular location with a free-flow icon. More specifically, atstep 3700, the method retrieves sensor location information for asensor. At step 3705, the method receives traffic information associatedwith the location of the sensor or traffic information from the sensor.At step 3710, the method determines whether the received trafficinformation has data indicating heavy traffic for the location. If thetraffic information has data indicating the heavy traffic, the methoddisplays a poor traffic icon at the location of the sensor at step 3715.At step 3720, the method determines whether the received trafficinformation has data indicating moderate traffic for the location. Ifthe traffic information has data indicating moderate traffic, the methoddisplays a moderate traffic icon at the location of the sensor at step3725. At step 3730, the method determines whether the received trafficinformation has data indicating that the sensor is broken. If thetraffic information has data indicating that the sensor is broken, themethod displays a sensor inoperable icon at the location of the sensorat step 3735. At step 3740, the method determines whether the receivedtraffic information has no data at all. If the traffic information hasno data, the method displays a free-flow traffic icon at the location ofthe sensor at step 3745. Those skilled in the art will appreciate thatthe above method broadcasts data for indicating broken sensors.

In general, a traffic information report (i.e., a complete nationaltraffic report) is updated at every five (5) minute intervals butbroadcast of the traffic information report can occur at a faster cycle(e.g., every minute). FIG. 38 shows an embodiment that adds a header3800 to each traffic information report pursuant to aspects of theinvention. The header 3800 allows the embodiment to skip or filterbroadcast reports that the embodiment has already processed. Morespecifically, the embodiment of FIG. 38 provides a method for adding aheader to allow a navigation device to read only updated trafficinformation in order to reduce a processing requirement of thenavigation device, as diagrammed in FIG. 39. At step 3900, a navigationdevice (e.g., the navigation device 14 shown in FIG. 1 a) receives atraffic report. At step 3905, the navigation device determines if theheader of the received traffic report is the same as a previouslyreceived header. If the header is the same as the previously receivedheader, the traffic report is discarded at step 3910. If the header isnot the same as the previously received header, the navigation deviceprocesses the received traffic report at step 3915. It should beappreciated that the above-described mechanisms and process for adding aheader to a traffic report are for exemplary purposes only and that theinvention is not limited thereby.

In general, when a traffic supplier via a one-to-many network broadcaststraffic information (e.g., U.S. traffic information), a navigationdevice needs to filter the broadcasted information down to informationrelating to a specific location of the device or the device would haveto receive and process non-related or useless traffic information. FIG.40 shows an embodiment of a navigation device that uses triangulation ofrepeaters 4000 a, 4000 b to determine a specific location or position4010 of the navigation device. In this embodiment, it should beappreciated that the navigation device does not need a GPS navigationsystem to determine location. More specifically, the embodiment of FIG.40 provides a method for filtering of traffic information throughtriangulation of repeaters 4000 a, 4000 b to determine a specificlocation, as diagrammed in FIG. 41. At step 4105, the method determineswhether there is a reception from repeaters 4000 a, 4000 a. In addition,the method may determine whether there is a reception from a satellite4020. If there is (or are) the necessary reception(s), the methodreceives a signal or signals from each of the repeaters 4000 a, 4000 band/or the satellite 4020 at step 4110. The method then calculates acurrent position 4010 (e.g., a current position of a vehicle) bytriangulation at step 4115 and determines the current position 4010 atstep 4120.

Once the current position has been determined, the method can thenfilter traffic information as described in the embodiment shown in FIG.42. That is, the embodiment may filter the traffic information down tofirst radius 4200 a and/or a second radius 4200 b of a determinedcurrent position 4010. The first radius 4200 a and/or second radius 4200b can be a five, ten, twenty, and/or thirty mile radius of the currentposition 4010. More specifically, the embodiment of FIG. 42 provides amethod for filtering of traffic information, as diagrammed in FIG. 43.At step 4300, the method determines whether there is a specific radius4200 a, 4200 b for traffic filtering. If there is the specific radius4200 a, 4200 b, the method uses the traffic information only inside theparameter of the specific radius 4200 a, 4200 b to filter trafficinformation at steps 4310 and 4320. If there is no specific radius, themethod sets a radius 4200 a, 4200 b to filter at step 4305 and thenmoves to steps 4310 and 4320.

FIG. 44 shows an embodiment of a method that requires a user to scrollto the needed traffic information in order to reduce displaydistractions. Specifically, at step 4400, a navigation device (e.g., anavigation device having no GPS) receives filtered traffic information.At step 4405, a user of the navigation device scrolls down a trafficdisplay of the navigation device to select an applicable area (e.g., anapplicable freeway). At step 4410, the user selects or picks theapplicable area (e.g., the applicable freeway). At step 4420, the userpushes a detail button (e.g., 3425 shown in FIG. 34) on the navigationdevice and the navigation device list all applicable details of theapplicable area at step 4430.

As envisioned, an embodiment of the invention uses four parameters todefine specific traffic information for a user in a vehicle. The fourparameters are a user's state, metro, county, and city. FIG. 45 shows amethod of the present embodiment that determines and filters trafficinformation for the user based on the four parameters. At step 4520,when a navigation device is in a range of a multiple source databroadcast area, the navigation device calculates approximate positionfrom the delay of the multiple source broadcast signal(s) (e.g., viarepeaters 4000 b, 4000 c in FIG. 40). The navigation device thendisplays (or filters) traffic information of the determined currentposition (e.g., 4010 in FIGS. 40, 42) of the vehicle at step 4530.However, if the vehicle is out of the range of the multiple sourcebroadcast signal area (i.e., the navigation device can not calculate thecurrent position) then the navigation device displays a candidate areamenu to the user at step 4500. At step 4510, the user then selects oneor more of the four parameters described above until a desired trafficbroadcast information signal is obtained (or filtered). In addition,each broadcasted traffic information of an embodiment may include aheader written such that it allows the navigation device to extractinformation associated with the four parameters. It should beappreciated the addition of the header allows the navigation device tofilter out traffic information having headers (e.g., with parameters)not specified by the user. Moreover, if the location information issuccessfully provided to the user, an embodiment of the inventionreduces location header information until the user specifies otherparameters so that the provision of redundant header information can bereduced.

FIG. 46 shows an embodiment of a broadcast methodology that reduces thebroadcasting of redundant traffic information. More specifically, anavigation device of the embodiment includes a static map 4600 of ametro or a city. A traffic supplier (and/or a remote location) of theembodiment only broadcasts traffic information data 4620 having trafficspeed graphic data and a map number. The embodiment does not have tobroadcast the static map 4600. In addition, the navigation deviceincludes a filter that displays detailed traffic flow data 4630 around acurrent position 4610 (e.g., determined via embodiments of FIGS. 40 and42) on the map 4600 and displays less traffic flow data far from thecurrent position 4600. The current position can be determined by a GPSnavigation system. In addition, the increasing traffic-jam portion ofthe traffic information should have top priority for display in theembodiment and the reducing traffic-jam portion of the trafficinformation should disappear from the display of the navigation devicefaster than other traffic jam information in the embodiment. It shouldbe appreciated that the embodiment of FIG. 46 allows a driver to focuson the important information and reduces the amount of driverdistractions.

As envisioned in an embodiment of the invention, a user may travel on aroute and receive traffic information about a traffic incident and/or atraffic congestion ahead of the route. If the user is unfamiliar withthe area of the route, a user may not know how to avoid the trafficincident and/or congestion. FIG. 47 shows an embodiment of a method thatprovides an option for a user of a navigation device (e.g., 14 in FIG. 1a) to request a calculation of a new route that will avoid the trafficincident and/or the congestion.

At step 4700 of FIG. 47, the method calculates a route to a destination.At step 4705, the method receives traffic information (e.g., U.S.traffic information). At step 4710, the method displays or shows to auser the traffic information on the current calculated route to thedestination. At step 4715, the method determines whether to calculate anew route (or reroute) for the user so that the user can avoid thetraffic shown by the traffic information. If the new route is to becalculated, the method calculates the new route at step 4720. If the newroute is not to be calculated, the method moves to step 4725 and keepsthe current calculated route.

Alternatively, in a case where a user is familiar with the area of theroute and goes off-route to avoid the traffic incident and/orcongestion, an embodiment of a navigation device of the inventioncalculates a new route (or recalculate a new route) that avoids thetraffic incident and/or the congestion after the user goes off-route. Itshould be appreciated that this embodiment increases the convenience ofthe user by providing a recalculation function (e.g., anticipating auser mistake) based on traffic information.

To avoid zigzag routing during a reroute function, an embodiment of theinvention provides a method to limit the reroute onto an existing routeto avoid zigzagging. More specifically, FIG. 48 b shows an embodiment ofthe invention that considers factors, such as a vehicle's position,speed, heading, destination, incident severity, time of reported trafficinformation, and/or estimated time for a traffic to clear, to calculatean optimized route 4810. In addition, the embodiment pursuant to aspectsof the invention limits the new optimized route 4810 to no more than tworeroutes back to an existing route 4800 within a predetermined distance.This embodiment reduces zigzigging effect of recalculating and returningto the existing route as compared with the embodiment shown in FIG. 48a.

FIG. 49 shows a method of the embodiment of FIG. 48 b that reduces azigzagging effect. At step 4900, a navigation device is set at a routeguidance mode. At step 4905, the navigation device calculate an existingroute 4800. At step 4910, the navigation device receives new trafficinformation. At step 4915, the navigation device determines whether toreroute a user of the navigation to a new route 4810. If the navigationdevice calculates the new route 4810 with the new traffic information,the new route 4810 is compared with the existing route 4800 to determinewhether the new route 4810 has been rerouted back to the existing route4800 for more than two times at step 4920. If the route 4810 has beenrerouted more than twice back to the existing route 4800, the methodmoves back to 4925 and maintains the existing route 4800 for the user.If the route 4810 has not been rerouted more than twice back to theexisting route 4800, the navigation device displays the new alternativeroute calculated with the traffic information at step 4930.

Embodiments of the invention use a routing algorithm having a costfunction that takes into account road speed, distance, road class,and/or other factors to calculate the cost of taking a certain route (orroad) to a destination. Traffic information wherever available can alsobe used by the routing algorithm to calculate the cost of a road linkwhen finding the best route. An easy method for a routing algorithm tocalculate a good route using traffic information is to translate trafficinformation into an appropriate speed and then substitute this speedinto the cost function.

In certain embodiments, some traffic information is already transmittedwith a speed value that can be directly substituted into the costfunction. However, depending on the location of the traffic informationand the lifetime of a specific piece of traffic information, it mightnot be a good idea to directly substitute the speed into the costfunction. For example, there may a fatal accident reported close to SanFrancisco that has reduced the speed of a major road in San Franciscodown to zero (0) mph and at the point of leaving Los Angeles to SanFrancisco, it usually does not make sense to substitute that speed(i.e., 0 mph) in San Francisco into the cost function to cause therouting algorithm to avoid that road in San Francisco because by thetime that the accident location is reached it is very likely that theincident will be cleared. Accordingly, an embodiment of the inventionmodulates the speed calculated from traffic information to take intoaccount the location of traffic information and/or its expectedexpiration time.

FIG. 50 shows an embodiment of the invention that provides a method forcalculating a distance threshold (D_(T)). The distance threshold(D_(T)), specifies a distance value at which it is likely that trafficinformation (i.e., a problem location) that exists past this distancevalue from a current location of a vehicle will expire before thevehicle can reach the traffic problem (i.e., the location reported bythe traffic information). In this embodiment, an expiration time shouldbe assigned to each piece of traffic information. This expiration timecan be calculated based on historical data for similar types ofincidents in similar types of road conditions. As is shown in FIG. 50,the threshold distance (D_(T)) should be calculated such that itincreases as the expiration time increases.

FIG. 51 shows an alternate embodiment that provides a method fordetermining the distance threshold (D_(T)) based on the density of theroad network (e.g., the road network is more dense in city areas than inrural areas). The distance threshold (D_(T)) is determined such that itdecreases as the road network becomes more dense.

FIG. 52 shows another embodiment of the invention that provides a methodfor calculating a speed of a link for a route calculation using adistance threshold (D_(T)) from a current vehicle position to thelocation of the traffic information. For any traffic information that islocated within the distance threshold (D_(T)), the speed specified bythe traffic information (S_(T)), should be used. Otherwise, if thetraffic information lies outside of the threshold distance then thespeed included in the onboard database (S_(DB)) should be used for routecalculation purposes.

A further embodiment of the invention provides a method in which thespeed of a link used by the routing algorithm is calculated by takinginto account both the dynamic speed from real-time traffic information(S_(T)) and the static speed stored in a map database (S_(DB)). Trafficinformation that is located far away from the vehicle's current positionshould have less effect on routing than information that is close to thevehicle. One way to do this is to calculate the speed of the link asshown FIG. 52 a or 52 b. That is, as shown by the linear process of FIG.52 a and the non-linear process of 52 b, for traffic information locatedvery close to the current location, the speed from the live trafficinformation (S_(T)) is used for the link. However, as the locationtraffic information approaches some threshold distance (D_(T)), thespeed of the link should be calculated such that it asymptoticallyapproaches the value of the speed in the database (S_(DB)).

It should be appreciated that the above-described mechanisms and processfor using a distance threshold (D_(T)), a dynamic speed from real-timetraffic information (S_(T)), and a static speed stored in a map database(S_(DB)) are for exemplary purposes only and that the invention is notlimited thereby.

Having thus described a preferred embodiment of a method and system fortraffic management between a vehicle and a remote location, it should beapparent to those skilled in the art that certain advantages of thewithin system have been achieved. It should also be appreciated thatvarious modifications, adaptations, and alternative embodiments thereofmay be made within the scope and spirit of the present invention. Forexample, the use of broadcast communication networks has beenillustrated, but it should be apparent that many of the inventiveconcepts described above would be equally applicable to the use of othernon-broadcast communication networks.

1-29. (canceled)
 30. In a vehicle navigation system, a method fordisplaying a travel route, comprising the steps of: (a) determining acurrent location of the vehicle navigation system; (b) receiving trafficinformation packets from a remote location, each traffic informationpacket comprising at least one assigned weight factor; (c) determiningfor each traffic information packet received in said step (b) whetherthe at least one assigned weight factor meets a threshold prioritylevel; (d) filtering any traffic information packets for which therespective at least one assigned weight factor does not meet thethreshold priority level; (e) calculating the travel route, based atleast in part on any traffic information packets for which therespective at least one assigned weight factor meets the thresholdpriority level; and (f) displaying the calculated travel route on avisual display screen.
 31. The method as recited in claim 30, whereinsaid step (c) comprises determining whether the at least one assignedweight factor meets a threshold priority level relating to location ofat least one traffic incident.
 32. The method as recited in claim 30,wherein said step (c) comprises determining whether the at least oneweight assigned factor meets a threshold priority level relating to timewhen at least one traffic incident occurred.
 33. The method as recitedin claim 30, wherein said step (c) comprises determining whether thereceived traffic information packets relate to traffic conditions withina threshold distance from the vehicle navigation system.
 34. The methodas recited in claim 30, further comprising adjusting the thresholdpriority level based on time of day during which a user of the vehiclenavigation system is commuting.
 35. The method as recited in claim 30,wherein said step (d) comprises discarding traffic information packetsfor which the respective at least one assigned weight factor does notmeet the threshold priority level.
 36. The method as recited in claim30, wherein said step (a) comprises receiving positioning informationfrom a satellite navigation system.
 37. The method as recited in claim36, wherein receiving positioning information comprises receiving thepositioning information from the satellite navigation system at thestart-up of the vehicle navigation system.
 38. The method as recited inclaim 30, wherein said step (a) comprises obtaining positioninginformation from a memory device of the vehicle navigation system. 39.In a vehicle navigation system, a method for displaying at least onetravel route, comprising the steps of: (a) determining a currentlocation of the vehicle navigation system; (b) receiving trafficinformation from the remote location; (c) determining whether thetraffic information received in said step (b) relates to trafficconditions located within a first distance from the vehicle navigationsystem; (d) filtering traffic information that is determined in saidstep (c) to relate to traffic conditions located farther than the firstdistance from the vehicle navigation system; (e) calculating a firsttravel route, based at least in part on any traffic information receivedin said step (b) that relates to traffic conditions located within thefirst distance from the vehicle navigation system; and (f) displayingthe calculated first travel route on a visual display screen.
 40. Themethod as recited in claim 39, wherein said step (c) comprisesdetermining whether the traffic information received in said step (b)relates to traffic conditions located within a predetermined distancefrom the vehicle navigation system.
 41. The method as recited in claim39, wherein said step (c) comprises determining whether the trafficinformation received in said step (b) relates to traffic conditionslocated within a user selected distance from the vehicle navigationsystem.
 42. The method as recited in claim 39, wherein said step (c)comprises determining whether the traffic information received in saidstep (b) relates to traffic conditions located within an approximatelyfifteen mile distance from the vehicle navigation system.
 43. The methodas recited in claim 39, further comprising the steps of: (g) determiningwhether the traffic information received in said step (b) relates totraffic conditions located within a second distance from the vehiclenavigation system; (h) filtering traffic information that is determinedin said step (g) to relate to traffic conditions located farther thanthe second distance from the vehicle navigation system; and (i)calculating a second travel route, based at least in part on any trafficinformation received in said step (b) that relates to traffic conditionslocated within the second distance from the vehicle navigation system.44. The method as recited in claim 39, wherein said step (d) comprisesdiscarding traffic information that is determined in said step (c) torelate to traffic conditions located farther than the first distancefrom the vehicle navigation system.
 45. The method as recited in claim39, wherein said step (a) comprises receiving positioning informationfrom a satellite navigation system.
 46. The method as recited in claim45, wherein receiving positioning information comprises receiving thepositioning information from the satellite navigation system at thestart-up of the vehicle navigation system.
 47. The method as recited inclaim 39, wherein said step (a) comprises obtaining positioninginformation from a memory device of the vehicle navigation system. 48.In a vehicle navigation system, a method for displaying at least onetravel route, comprising the steps of: (a) determining a currentlocation of the vehicle navigation system; (b) receiving trafficinformation from the remote location; (c) determining whether thetraffic information received in said step (b) exceeds a first level ofmemory capacity of the vehicle navigation system; (d) filtering thetraffic information received in said step (b) when it is determined insaid step (c) that the traffic information exceeds the first level; (e)calculating a travel route between a first location and a secondlocation, based at least in part on the traffic information received insaid step (b); and (f) displaying the calculated travel route on avisual display screen.
 49. The method as recited in claim 48, whereinfiltering the traffic information in said step (d) continues until thetraffic information does not exceed the first level.
 50. The method asrecited in claim 48, wherein said step (c) comprises determining whetherthe traffic information received in said step (b) exceeds apredetermined level of the memory capacity.
 51. The method as recited inclaim 48, wherein said step (c) comprises determining whether thetraffic information received in said step (b) exceeds a user selectedlevel of the memory capacity.
 52. The method as recited in claim 48,wherein said step (c) comprises determining whether the trafficinformation received in said step (b) exceeds approximately ninetypercent of the memory capacity.
 53. The method as recited in claim 48,wherein filtering the traffic information in said step (d) comprises:(i) separating the traffic information received in said step (b) intotraffic information relating to traffic conditions located within apredetermined distance from the vehicle navigation system and trafficinformation relating to traffic conditions located farther than thepredetermined distance from the vehicle navigation system; (ii)discarding the traffic information that relates to traffic conditionslocated farther than the predetermined distance from the vehiclenavigation system; (iii) determining whether the traffic informationthat relates to traffic conditions located within the predetermineddistance from the vehicle navigation system exceeds the first level ofthe memory capacity; and (iv) repeating said steps (i), (ii) and (iii)until it is determined in said step (iii) that the traffic informationdoes not exceed the first level of the memory capacity, wherein eachtime said step (i) is repeated the predetermined distance from thevehicle navigation system is reduced.
 54. The method as recited in claim53, wherein step (i) comprises separating traffic information relatingto traffic conditions located within approximately fifteen miles fromthe vehicle navigation system when the traffic information is separatedin said step (i) a first time.
 55. The method as recited in claim 54,wherein step (i) further comprises separating traffic informationrelating to traffic conditions located within approximately ten milesfrom the vehicle navigation system when the traffic information isseparated in said step (i) a second time.
 56. The method as recited inclaim 48, further comprising: (g) determining whether the trafficinformation received in said step (b) exceeds a second level of memorycapacity of the vehicle navigation system; and (h) filtering the trafficinformation received in said step (b) when it is determined in said step(g) that the traffic information exceeds the second level.
 57. Themethod as recited in claim 48, wherein said step (d) comprisesdiscarding traffic information that is determined in said step (c) toexceed the first level of the memory capacity.
 58. The method as recitedin claim 48, wherein said step (a) comprises receiving positioninginformation from a satellite navigation system.
 59. The method asrecited in claim 58, wherein receiving positioning information comprisesreceiving the positioning information from the satellite navigationsystem at the start-up of the vehicle navigation system.
 60. The methodas recited in claim 48, wherein said step (a) comprises obtainingpositioning information from a memory device of the vehicle navigationsystem.
 61. In a vehicle navigation system, a method for displaying atravel route, comprising the steps of: (a) determining a currentlocation of the vehicle navigation system; (b) receiving trafficinformation that relates to traffic conditions located within a firstdistance from the vehicle navigation system from a remote location; (c)determining whether the traffic information received in said step (b)exceeds a first level of memory capacity of the vehicle navigationsystem; (d) acquiring additional traffic information that relates totraffic conditions located within a second distance from the vehiclenavigation system from the remote location, when it is determined insaid step (c) that the traffic information does not exceed the firstlevel of the memory capacity; (e) calculating the travel route, based atleast in part upon the traffic information received in said step (b) andany additional traffic information acquired in said step (d); and (f)displaying the calculated travel route on a visual display screen. 62.The method as recited in claim 61, wherein said step (c) comprisesdetermining whether the traffic information received in said step (b)exceeds approximately ninety percent of the memory capacity.
 63. Themethod as recited in claim 61, wherein step (b) comprises receivingtraffic information that relates to traffic conditions located withinapproximately fifteen miles from the vehicle navigation system.
 64. Themethod as recited in claim 61, wherein step (d) comprises receivingtraffic information that relates to traffic conditions located withinapproximately twenty-five miles from the vehicle navigation system. 65.The method as recited in claim 61, wherein said step (a) comprisesreceiving positioning information from a satellite navigation system.66. The method as recited in claim 65, wherein receiving positioninginformation comprises receiving the positioning information from thesatellite navigation system at the start-up of the vehicle navigationsystem.
 67. The method as recited in claim 61, wherein said step (a)comprises obtaining positioning information from a memory device of thevehicle navigation system.